fix(project-management): address a project by its id, not its name (#1363) - #1377

Closes #1363.

Problem

Seven @stable tests across four specs hard-failed on the 2026-08-07 daily (run 31163810520) with one shape: a project the backend confirms exists (POST /api/v1/projects → 201) never resolves in the home sidebar. Every one failed on all three attempts, across both shards and worker indices 2–17, outside the run's 108 s outage window — so not environmental. They were quarantined manually at triage (@stable removed and test.fixme added).

Upstream 23f91d8587 (fix(authz): support scoped project visibility, langflow-ai/langflow#14429) re-keyed both testids from the project name to its id, on the release-1.12.0 line the nightly is cut from:

- data-testid={`sidebar-nav-${item.name}`}
+ data-testid={`sidebar-nav-${item.id}`}
- "more-options-button" + `_${convertTestName(item?.name ?? "")}`
+ data-testid={`more-options-button_${item.id}`}

Verdict: internal rename of an automation hook — NOT a product regression

Read from the live DOM on 1.12.0.dev20, not inferred from the commit:

entry   data-testid="sidebar-nav-<uuid>"           id="sidebar-nav-<uuid>"
kebab   data-testid="more-options-button_<uuid>"   aria-label="Options for <name>"
wrapper data-project-id="<uuid>"

The name is still the entry's text and the kebab's accessible name, so nothing a user or a screen reader perceives was lost — data-testid is a test hook, not a product contract. Keying on the id is also the more correct choice under the change that introduced it: visibility is now per-principal, and a project name is not unique across principals while its id is. No REGRESSIONS.md row is owed and no upstream ticket is filed. Full reasoning recorded on the issue.

Ruled out rather than assumed: the ProjectRenamePermission wrapper the same commit adds is children(can(projectId, "write")) — it always renders its child, and canRename only guards onDoubleClick. Both projects render live.

Fix

Addressing lives in one place — tests/helpers/ui/project-sidebar.ts — matching both spellings as a single locator.

That is not a hedge. main still renders the name-derived testid, and manual.yml dispatches the @stable set against 1.11.x release candidates before every sign-off — pinning the id alone would trade seven tests red on the nightly for seven red on the lane that signs releases off. The two branches can never both match: an entry carries exactly one testid, and a project's name is never another project's uuid. The name branch carries its own deletion trigger, and it is the only place that spells it.

Rejected: editing each spec in place. The issue's own directive puts the fix in the shared layer, and addressing by the id the create response already returns removes the #1023 ambiguity instead of trading one name for another.

Consumers updated: MainPage (deleteProject / clickProject / uploadFlowByDragDrop), createProjectThroughSidebar / renameProjectThroughSidebar, cleanOldFolders, the four quarantined specs, and the two latent ones.

Second defect, riding on the first

cleanOldFolders drove the kebab through the name-derived testid, so from dev20 on it deleted nothing and merely timed out on a click — the mechanism behind the New Project → New Project (5) accumulation the daily's retries recorded inside a single test. It now sweeps through the REST API: this is teardown of the previous run and must not depend on the UI state the test it precedes is about to assert on, the argument removeLeftoverRenamedProject already makes in the same file.

Measured on 1.12.0.dev20: 3 New Project* projects seeded via POST /api/v1/projects/, spec run once — 0 of 3 survived.

One observable had to change

The id-derived testid does not change with a rename, so asserting on it would pass whether the rename committed or not. renameProjectThroughSidebar now asserts the entry's text, and returns the project under its new name (which is what later assertions must address it by on 1.11.x, where the testid does change).

Scope notes

• Quarantine lifted on all 7 tests — test.fixme removed and @stable restored.
• The two specs carrying the same addressing but no @stable, hence latently broken and invisible to the daily, are fixed here as the issue requires: folder-drag-drop-flow.spec.ts, flow-navigation-between-folders.spec.ts.
• The @destructive loop kept its assertions; its isVisible() fallback to more-options-button_*.first() is gone — it could delete a folder other than the one it had just hovered. The #1008 known-defect declaration still fires.
• No assertion was weakened anywhere; every changed line is addressing, not verdict.
• Out of scope, filed separately: mcp-server-starter-projects leaks one flow and one project per run, hidden by the next run's cleanup #1376 — mcp-server-starter-projects leaks one flow and one project per run, masked by the next run's cleanOldFolders. A cleanup defect, not an addressing one.

Covered tests

Unit coverage (npm run test:units)

project-sidebar.test.ts asserts by selection, not string equality — each case compiles the selector and runs it against a data-testid: it matches the id spelling (nightly) and the name spelling (main/1.11.x); the kebab matches the id and the slugified name and not the raw one; matching is exact, so New Project does not match New Project (3); a name carrying " or \ still yields a well-formed selector.

clean-old-folders.test.ts pins the sweep's end state, not its calls: it deletes every New Project* and nothing else, deletes by id and never through the sidebar, reads both response shapes, does not throw on a failed list, does not abort on one undeletable leftover, and does not sweep a name that merely contains "New Project".

Validation (nightly 1.12.0.dev20, --workers=1 --retries=0)

• npm run typecheck ✅ · npm run lint ✅ (0 errors) · npm run test:units ✅ 531/531 · npm run test:scripts ✅ 795/795
• 5 clean runs of the six specs, 11 passed each (~39 s); @destructive green isolated (1 passed)
• --trace=on ✅ — ran normally (23 s), no sign of the Simple Agent-family hang
• Zero 🚨 Backend Error attributable to this change. Two advisory entries appear, both from mcp-server-starter-projects test 2, which this PR does not touch and which reproduces them on main: the 409 Server already exists. is that test's own assertion, and the intermittent 500 on DELETE /api/v1/flows/ is sqlite3.OperationalError: database is locked in the cascade delete — the already-filed [Daily #962] api-folders DELETE returns 500 instead of 204 (recurrent) #965/LE-2020 contention class, read from the container's traceback.
• Orphan check: flows and projects counted via GET /api/v1/flows/?get_all=true and GET /api/v1/projects/ before and after a clean run — 0 delta for all five project-management specs. The +1/+1 on the MCP spec is pre-existing and filed as mcp-server-starter-projects leaks one flow and one project per run, hidden by the next run's cleanup #1376.

Force-fail — executed, one mutation per test in scope

Revert proven: grep FF_MUTATION over tests/ returns 0, followed by a final green run.

Dependencies

None — pure UI plus REST. No LLM, no provider key. Parallel-safe: every test addresses only projects it created, and cleanup is id-scoped.

🤖 Generated with Claude Code